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Foreword 



rd , 



This Technical Specification has been produced by the 3 Generation Partnership Project (3GPP). 

The contents of the present document are subject to continuing work within the TSG and may change following formal 
TSG approval. Should the TSG modify the contents of the present document, it will be re-released by the TSG with an 
identifying change of release date and an increase in version number as follows: 

Version x.y.z 

where: 

x the first digit: 

1 presented to TSG for information; 

2 presented to TSG for approval; 

3 or greater indicates TSG approved document under change control. 

y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections, 
updates, etc. 

z the third digit is incremented when editorial only changes have been incorporated in the document. 



Introduction 

The absence of security in Signalling System No. 7 (SS7) networks is an identified security weakness in 2G systems. 
This was formerly perceived not to be a problem, since the SS7 networks were the provinces of a small number of large 
institutions. This is no longer the case, and so there is now a need for security precautions. 

For 3G systems it is a clear goal to be able to protect the core network signalling protocols, and by implication this 
means that security solutions must be found for both SS7 and IP based protocols. 

Various protocols and interfaces are used for control plane signalling within and between core networks. The security 
services that have been identified as necessary are confidentiality, integrity, authentication and anti-replay protection. 
These will be ensured by standard procedures, based on cryptographic techniques. 
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Scope 



This technical specification covers the security mechanisms and procedures necessary to protect the MAP protocol. The 
complete set of enhancements and extensions to facilitate security protection for the MAP protocol is termed MAPsec 
and it covers transport security in the MAP protocol itself and the security management procedures. 

The security mechanisms specified for MAP are on the application layer. This means that MAPsec is independent of the 
network and transport protocols to be used. This specification also includes automatic key management mechanisms to 
update the security associations used to protect the MAP signalling. 

This technical specification contains the stage-2 specification for security protection of the MAP protocol. The actual 
implementation (stage-3) specification can be found in the MAP stage-3 specification, TS 29.002 [4]. 
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a GSM document), a non-specific reference implicitly refers to the latest version of that document in the same 
Release as the present document. 
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[6] ISO/IEC 9797: "Information technology — Security techniques — Message Authentication 

Codes (MACs) -- Part 1: Mechanisms using a block cipher", Ed.l, 1999-12-16. 

[7] FIPS Publication 197: "Specification for the Advanced Encryption Standard (AES)", 

November 26, 2001. 

[8] draft-arkko-map-doi-05-pa2.txt: "The MAP Security Domain of Interpretation for ISAKMP". 



3 Definitions, symbols and abbreviations 

3.1 Definitions 

For the purposes of the present document, the following terms and definitions apply. 

Anti-replay protection: Anti -replay protection is a special case of integrity protection. Its main service is to protect 
against replay of self-contained packets that already have a cryptographical integrity mechanism in place. 

Confidentiality: The property that information is not made available or disclosed to unauthorised individuals, entities 
or processes. 
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Data integrity: The property that data has not been altered in an unauthorised manner. 

Data origin authentication: The corroboration that the source of data received is as claimed. 

Entity authentication: The provision of assurance of the claimed identity of an entity. 

Key freshness: A key is fresh if it can be guaranteed to be new, as opposed to an old key being reused through actions 
of either an adversary or authorised party. 

Security Association: A logical connection created for security purposes. All traffic traversing a security association is 
provided the same security protection. The security association specifies protection levels, algorithms to be used, 
lifetimes of the connection etc. 

MAPsec: The complete collection of protocols and procedures needed to protect MAP messages. MAPsec can be 
divided into three main parts. These are (1) MAPsec transport security, (2) MAPsec Local Security Association 
distribution and (3) MAPsec Inter-domain Security Association and Key Management procedures. 



3.2 Symbols 



For the purposes of the present document, the following symbols apply: 



f6 

17 
Zd 
Ze 
Zf 



MAP encryption algorithm. 

MAP integrity algorithm. 

MAPsec interface between KACs belonging to different PLMNs 

MAPsec interface between KACs and MAP-NEs within the same PLMN 

The MAP application layer security interface between MAP-NEs engaged in security protected 

signalling. 



3.3 



Abbreviations 



For the purposes of the present document, the following abbreviations apply: 

AES Advanced Encryption Standard 

Dol Domain of Interpretation 

ESP Encapsulating Security Payload 

FALLBACK Fallback to unprotected mode indicator 

IETF Internet Engineering Task Force 

IKE Internet Key Exchange 

IP Internet Protocol 

IPsec IP security - a collection of protocols and algorithms for IP security incl. key mngt. 

ISAKMP Internet Security Association Key Management Protocols 

IV Initialisation Vector 

KAC Key Administration Centre 

MAC Message Authentication Code 

MAC-M MAC used for MAP 

MAP Mobile Application Part 

MAP-NE MAP Network Element 

MAPsec MAP security - the MAP security protocol suite 

MEA MAP Encryption Algorithm identifier 

MEK MAP Encryption Key 

MIA MAP Integrity Algorithm identifier 

MIK MAP Integrity Key 

NDS Network Domain Security 

NE Network Entity 

PPI Protection Profile Indicator 

PPRI Protection Profile Revision Identifier 

PROP Proprietary field 

SA Security Association 

SADB Security Association DataBase (also referred to as SAD) 

SPD Security Policy Database (sometimes also referred to as SPDB) 

SPI Security Parameters Index 
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TVP 



Time Variant Parameter 



3.4 



Conventions 



All data variables in this specification are presented with the most significant substring on the left hand side and the 
least significant substring on the right hand side. A substring may be a bit, byte or other arbitrary length bitstring. 
Where a variable is broken down into a number of substrings, the leftmost (most significant) substring is numbered 0, 
the next most significant is numbered 1, and so on through to the least significant. 



4 Principles of MAP application layer security 

This technical specification defines mechanisms for protecting the MAP protocol at the application layer. The MAP 
protocol may also be protected at the network layer when IP is used as the transport protocol. However, whenever inter- 
working with networks using SS7-based transport is necessary, protection at the application layer shall be used. 

The security measures specified in this TS are only fully useful if all interconnected operators use them. In order to 
prevent active attacks all interconnected operators must at least use MAPsec with the suitable protection levels as 
indicated in this specification and treat the reception of all MAP messages (protected and unprotected) in a uniform way 
in the receiving direction. 

Before protection can be applied, Security Associations (SA) needs to be established between the respective MAP 
network elements. Security associations define, among other things, which keys, algorithms, and protection profiles to 
use to protect MAP signalling. The necessary MAPsec-SAs between networks are negotiated between the respective 
Key Administration Centres (KACs) of the networks. The negotiated SA will be effective PLMN-wide and distributed 
to all network elements which implement MAP application layer security within the PLMN. Signalling traffic protected 
at the application layer will, for routing purposes, be indistinguishable from unprotected traffic to all parties except for 
the sending and receiving entities. 

Figure 1 gives an overview of the architecture used for MAPsec. 



PLMN A 



KAC A 



Ze 



Zf 



MAP 
NE A1 



MAP 
NE A2 



PLMNB 



Zd 



KAC B 



Zf 



Ze 



MAP 
NE B 



IKE "connection" 

Secure tunnel providing confidentiality and integrity protection 
Secured MAP operations 

Figure 1 : Overview of the Zd, Ze and Zf interfaces 

The following interfaces are defined MAPsec. 
- Zd-interface (KAC-KAC) 
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The Zd-interface is used to negotiate MAPsec Security Associations (SAs) between PLMNs. The traffic over Zd 
consists only of IKE negotiations. The negotiated MAPsec SAs are valid on a PLMN to PLMN basis. 

- Ze-interface (KAC-NE) 

The Ze-interface is located between MAP-NEs and a KAC from the same PLMN. This interface is used for 
transport of MAPsec SAs and the relevant security policy information from the KAC to the MAP-NE. 

- The Zf-interface (NE-NE) 

The Zf-interface is located between MAP-NEs. The MAP-NEs may be from the same PLMN or from different 
PLMNs (as shown in figure 1). The MAP-NEs use MAPsec SAs received from a KAC to protect the MAP 
operations. The MAP operations within the MAP dialogue are protected selectively as specified in the applied 
MAPsec protection profile. The interface applies to all MAPsec transactions, intra- or inter-PLMN. 

The security services provided by MAPsec are: 

data integrity; 

data origin authentication; 

anti-replay protection; 

confidentiality (optional). 
Annex B includes detailed procedures on how secure MAP signalling is performed between two MAP-NEs. 



5 MAP security (MAPsec) 

5.1 A Properties and tasks of Key Administration Centres (KACs) 

Key Administration Centres (KACs) are entities that are used for negotiating MAPsec SAs on behalf of MAP-NEs. The 
KACs are defined to handle communication over these interfaces: 

the Zd-interface, which is located between KACs from different PLMNs. The IKE protocol with support for 
MAPsec Dol shall be used over this interface. 

the Ze-interface, which is located between a KAC and a MAP-NE within the same PLMN is used to transfer 
MAPsec SAs and security policy from KACs to MAP-NEs. The SAs and security policy must be transferred in a 
secure manner. 

When a MAP-NE needs to establish a secure connection towards another MAP-NEs it will request a MAPsec SA from 
the KAC if it cannot find any appropriate MAPsec SA in its local SAD. The KAC will then either provide an existing 
MAPsec SA or negotiate a new MAPsec SA, before returning the MAPsec SA to the MAP-NE. 

A MAPsec SA is valid for all MAP communications between the two PLMNs for which it is negotiated. That is, the 
same MAPsec SA shall be provided to all MAP-NEs in PLMN A for communication with MAP-NEs in PLMN B. Each 
PLMN can have one or more KACs. Each KAC will be responsible to define MAPsec SAs with a well-defined set of 
reachable PLMNs. The number of KACs in a PLMN will depend on the need to differentiate between the externally 
reachable destinations, the need to balance the traffic load and to avoid single points of failure. 

KACs perform the following operations: 

Negotiate SAs for MAPsec with other KACs belonging to other network operators. This action is triggered either 
by request for a MAPsec S A by a NE or by policy enforcement when MAPsec SAs should always be available. 
The negotiation of MAPsec SAs is performed at Zd-interface using IKE protocol with MAPsec Dol. 

Convert specific negotiated SA parameter so that they can be understood by NEs. In particular, the KAC shall 
convert negotiated SA duration in seconds as negotiated in MAPsec Dol to UTC absolute time format. 

Perform refresh of MAPsec SAs. This could be triggered internally by S A lifetime supervision depending on the 
policies set by the operator. 
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Distribute MAPsec SAs and policy information to NEs belonging to the same PLMN as the KAC. 

KAC shall be able to securely transmit MAPsec SAs and policy information to the NEs within its PLMN. 

KACs are also responsible for the maintenance of the following databases: 

KAC-SPD-MAP: Defines the scope, the security policy, in which MAP-SAs may be negotiated (e.g. allowed 
MAP-PPs, Algorithms, SA-lifetimes). This database is updated on operator initiative in the framework of the 
roaming agreements. 

NE-SPD-MAP: A database in a KAC containing the MAP security policy information that will be used by an 
NE in protecting MAP messages (e.g. value of "Fallback to unprotected Mode Indicator" and table of protected 
MAPsec operation components). This is held to update the NEs. 

- NE-SADB-MAP: A database in a KAC containing MAP-SA information. This is held to allow the KAC to 
update the NE. 

KACs are responsible for security sensitive operations and shall be physically secured. They shall offer capabilities for 
the secure storage of long-term keys used for IKE authentication. 

5.2 Properties and tasks of MAPsec enabled network elements 

MAPsec MAP-NEs shall maintain the following databases: 

NE-SPD-MAP: A database in an NE containing MAP security policy information (see clause 5.3); 

- NE-SADB-MAP: A database in an NE containing MAPsec-SA information. MAP-NEs shall monitor the SA 
hard expiry time and expired SAs shall be deleted from the database (see clause 5.4). 

MAPsec MAP-NEs shall be able to perform the following operations: 

Secure MAP signalling (i.e. send/receive protected or unprotected messages) according to information in NE- 
SPD-MAP and NE-SADB-MAP. The structure of protected messages is defined in clause 5.5 and the protection 
algorithms are defined in clause 5.6. 

- Communicate with the KAC in the same PLMN in order that the NE-SPD-MAP and NE-SADB-MAP in the NE 
can be updated. 

NE shall be able to securely receive MAPsec SAs and policy information from the KAC within its PLMN. 

5.3 Policy requirements for the MAPsec Security Policy 
Databases (SPD) 

Two security policy databases, KAC-SPD-MAP and NE-SPD-MAP, are required to implement MAPsec. KAC-SPD- 
MAP holds the information needed by the KACs to negotiate MAPsec SAs. NE-SPD-MAP holds the security policy 
information used by a NE element when applying MAPsec to message over the Zf-interface. A KAC holds a copy of 
NE-SPD-MAP in order to update the NEs in the same PLMN. 

NE-SPD-MAP entries define which MAP operation components are protected and which MAP SAs (if any) to use to 
protect MAP signalling based on the PLMN of the peer NE. There can be no local security policy definitions for 
individual NEs. Instead, SPD entries of different NEs within the same PLMN shall be identical. 

Fallback to unprotected mode: 

The "fallback to unprotected mode" (enabled/disabled) shall be available to the MAP-NE before any 
communication towards other MAP-NEs can take place. For the receiving direction, it is sufficient to have a 
single parameter indicating whether fallback for incoming messages is allowed or not. For the sending direction, 
the information should indicate for each destination PLMN whether fallback for outgoing messages is allowed or 
not; 

The use of the fallback indicators is specified in Annex B; 
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The security measures specified in this TS are only fully useful for a particular PLMN if it disallows fallback to 
unprotected mode for MAP messages received from any other PLMN. 

Table of MAPsec operation components: 

The security policy database (SPD) shall contain a table of MAPsec operation components for incoming 
messages. This table contains operation components which have to be carried in MAPsec messages with 
Protection Mode 1 or 2. The use of MAPsec operation components is specified in Annex B. 

Uniformity of protection profiles: 

In order to ensure full protection, a particular PLMN shall use the same protection profile for incoming MAPsec 
messages from all other PLMNs. In particular, full protection is not ensured when protection profile A (no 
protection) is used for some source PLMNs and other profiles are used for other source PLMNs. 

Explicit policy configuration: 

The SPD shall contain an entry for each PLMN the MAP-NE is allowed to communicate with. 

Editor's note: Some issues need to be investigated: Non-synchronised expiration times issue, mechanism to 
distinguish inbound/outbound SPDs ? 

5.4 MAPsec security association attribute definition 

The MAPsec security association shall contain the following data elements: 

- Destination PLMN-Id: 

PLMN-Id is the ID number of the receiving Public Land Mobile Network (PLMN). The value for the PLMN-Id 
is a concatenation of the Mobile Country Code (MCC) and Mobile Network Code (MNC) of the receiving 
network. 

- Security Parameters Index (SPI): 

SPI is a 32-bit value that is used in combination with Destination PLMN-Id to uniquely identify a MAPsec-SA. 

- Sending PLMN-Id: 

PLMN-Id is the ID number of the sending Public Land Mobile Network (PLMN). The value for the PLMN-Id is 
a concatenation of the Mobile Country Code (MCC) and Mobile Network Code (MNC) of the sending network. 

- MAP Encryption Algorithm identifier (ME A): 

Identifies the encryption algorithm. Mode of operation of algorithm is implicitly defined by the algorithm 
identifier. Mapping of algorithm identifiers is defined in clause 5.6. 

- MAP Encryption Key (MEK): 

Contains the encryption key. Length is defined according to the algorithm identifier. 

- MAP Integrity Algorithm identifier (MIA): 

Identifies the integrity algorithm. Mode of operation of algorithm is implicitly defined by the algorithm 
identifier. Mapping of algorithm identifiers is defined in section 5.6. 

- MAP Integrity Key (MIK): 

Contains the integrity key. Length is defined according to the algorithm identifier. 

: Protection Profile Revision Identifier (PPRI): 

Contains the revision number of the PPI. Length is 8 bits. PPRI-values are defined in section 6.3. 

- Protection Profile Identifier (PPI): 

Identifies the protection profile. Length is 16 bits. Mapping of profile identifiers is defined in section 6. 
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- SA Hard Expiry Time: 

Defines the actual expiry time of the S A. The hard expiry time shall be given in UTC time. 

- SA Soft Expiry Time: 

Defines soft expiry time of the S A for outbound traffic. The soft expiry time shall be given in UTC time. 

After the hard expiry time has been reached the S A shall no longer be used for inbound or outbound traffic. When the 
soft expiry time is reached, the SA shall not be used any longer for the outbound traffic unless no other valid SA exists. 

A MAPsec SA is uniquely identified by a destination PLMN-Id and a Security Parameters Index, SPI. As a 
consequence, during SA creation, the SPI is always chosen by the receiving side (i.e. the SPI for MAP communications 
from PLMN A to PLMN B is selected by KAC in PLMN B). 

If the SA is to indicate that MAPsec is not to be applied then all the algorithm attributes shall contain a NULL value. 

5.5 MAPsec structure of protected messages 

MAPsec provides for three different protection modes and these are defined as follows: 

Protection Mode 0: No Protection 

Protection Mode 1 : Integrity, Authenticity 

Protection Mode 2: Confidentiality, Integrity, and Authenticity 

MAP operations protected by means of MAPsec consist of a Security Header and the Protected Payload. Secured MAP 
messages have the following structure: 

1 Security Header | Protected Payload | 

In all three protection modes, the security header is transmitted in cleartext. 

In protection mode 2 providing confidentiality, the protected payload is essentially the encrypted payload of the original 
MAP message. For integrity and authenticity in protection mode 1, the message authentication code is calculated on the 
security header and the payload of the original MAP message in cleartext and it is included in the protected payload. 
The message authentication code in protection mode 2 is calculated on the security header and the encrypted payload of 
the original MAP message. In protection mode no protection is offered, therefore the protected payload is identical to 
the payload of the original MAP message. 

5.5.1 MAPsec security header 

For Protection Mode 0, the security header is a sequence of the following data elements: 

Security header = SPI 1 1 Original component Id 
For Protection Modes 1 and 2, the security header is a sequence of the following elements: 
Security header = SPI 1 1 Original component Id 1 1 TVP 1 1 NE-Id 1 1 Prop 

- Security Parameters Index (SPI): 

SPI is an arbitrary 32-bit value that is used in combination with the Destination PLMN-Id to uniquely identify a 
MAPsec-SA. 

- Original component Id: 

Identifies the type of component (invoke, result or error) within the MAP operation that is being securely 
transported (Operation identified by operation code, Error defined by Error Code or User Information). 
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- TVP: 

The TVP is used for replay protection of Secured MAP operations is a 32 bit time-stamp. The receiving network 
entity will accept an operation only if the time-stamp is within a certain time-window. The resolution of the 
clock from which the time-stamp is derived is 0.1 seconds. The size of the time-window at the receiving network 
entity is not standardised. 

- NE-Id: 



6 octets used to create different IV values for different NEs within the same TVP period. It is necessary and 
sufficient that NE-Id is unique per PLMN. (This is sufficient because sending keys are unique per PLMN.) The 
NE-Id shall be the E.164 global title of the NE without the MCC and MNC. 

- Proprietary field (PROP): 

4 octets used to create different IV values for different protected MAP messages within the same TVP period for 
one NE. The usage of the proprietary field is not standardised. 

5.5.2 Protected payload 

5.5.2.1 Protection Mode 

Protection Mode offers no protection at all. Therefore, the protected payload of Secured MAP messages in protection 
mode is identical to the original MAP message payload in cleartext. 

5.5.2.2 Protection Mode 1 

The protected payload of Secured MAP messages in protection mode 1 takes the following form: 

CleartextH f7(Security Header||Cleartext) 

where "Cleartext" is the payload of the original MAP message in cleartext. Therefore, in Protection Mode 1 the 
protected payload is a concatenation of the following information elements: 

Cleartext 

Message authentication code (MAC-M) calculated by the function f7 

Authentication of origin and message integrity are achieved by applying the message authentication code (MAC-M) 
function f7 with the integrity key defined by the security association to the concatenation of Security Header and 
Cleartext. The MAC-M length shall be 32 bits. 

5.5.2.3 Protection Mode 2 

The protected payload of Secured MAP Messages in protection mode 2 takes the following form: 

f6( Cleartext) || f7(Security Header|| f6( Cleartext)) 

where "Cleartext" is the original MAP message payload in cleartext. Confidentiality is achieved by encrypting Cleartext 
using the encryption function f6 with the confidentiality key defined by the security association and the initialisation 
vector (IV). Authentication of origin and integrity are achieved by applying the message authentication code (MAC-M) 
function f7 with the integrity key defined by the security association to the concatenation of Security Header and 
ciphertext. The MAC-M length shall be 32 bits. The length of the ciphertext is the same as the length of the cleartext. 
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5.6 MAPsec algorithms 

5.6.1 Mapping of MAPsec-SA encryption algorithm identifiers 

The MEA algorithm indication fields in the MAPsec-SA are used to identify the encryption algorithm and algorithm 
mode to be used. The mapping of algorithm identifiers is defined below. 

Table 1 : MAP encryption algorithm identifiers 



MAP Encryption Algorithm 
identifier 


Description 





Null 


1 


AES in counter mode with 128-bit key length (MANDATORY) 




-not yet assigned- 


15 


-not yet assigned- 



5.6.1 .1 Description of MEA-1 

The MEA-1 algorithm is AES [7] used in counter mode with a 128-bit key and 128-bit counter blocks as described in 
clause 6.5 of FIPS 800-38 A Recommendation for Block Cipher Modes of Operation [5]. The initial counter block T! is 
initialized with IV. Successive counter blocks Tj (J>1) are derived by applying an incrementing function over the entire 
block Tj_i (J>=2) (see Appendix B.l: The standard incrementing function of [5]). 

5.6.2 Mapping of MAPsec-SA integrity algorithm identifiers 

The MIA algorithm indication fields in the MAPsec-SA are used to identify the integrity algorithm and algorithm mode 
to be used. The mapping of algorithm identifiers is defined below. 

Table 2: MAP integrity algorithm identifiers 



MAP Integrity Algorithm 
identifier 


Description 





Null 


1 


AES in a CBC MAC mode with a 128-bit key (MANDATORY) 




-not yet assigned- 


15 


-not yet assigned- 



5.6.2.1 Description of MIA-1 

The MIA-1 algorithm is the ISO/IEC 9797 Part 1: padding method 2, MAC algorithm 1 (initial transformation= 1 , 
output transformation^). No IV used. The MAC-length m is 32-bits (see clause 5.6.1). See ISO/IEC 9797 [6] for more 
information. 

5.6.3 Construction of IV 

The IV used in the encryption shall be constructed as follows: 

IV = TVP II NE-Id II Prop II Pad 
The padding field is used to expand TVP 1 1 NE-Id 1 1 Prop to the IV length required by the cryptographic scheme in use. 
The IV length shall be 16 octets. The padding (Pad) shall be 2 octets with all bits set to zero. 
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6 MAPsec protection profiles 

6.1 Granularity of protection 

MAPsec protection is specified per MAP operation component. 

6.2 MAPsec protection groups 

This section specifies groups of messages and their protection modes at the operation component level. Individual 
protection groups or particular combinations of groups can then be used to construct protection profiles as specified in 
section 6.3. 

Combinations of overlapping protection groups are forbidden. Forbidden combinations are explicitly specified in 6.2.1 
below. 

The concept of "protection levels" is introduced to administrate the protection mode on operation component level. A 
protection level of an operation determines the protection modes used for the operation's components according to the 
following table. 

Table 3: MAPsec protection levels 



Protection 
level 


Protection mode for 
invoke component 


Protection mode for 
result component 


Protection mode for 
error component 


1 


1 








2 


1 


1 





3 


1 


2 





4 


2 


1 





5 


2 


2 





6 


2 









6.2.1 MAPsec protection groups 



6.2.1.1 



MAP-PG(O) - No Protection 



This MAP-PP does not contain any operation and it does not protect any information. It is useful however to have a 
"null" MAP-PP to use in situations where no security is required or is an option. This protection group cannot be 
combined with any other protection group. 

6.2.1 .2 MAP-PG(1 ) - Protection for Reset 

Table 4: PG(1) - Protection for Reset 



Application Context/Operation 


Protection Level 


ResetContext-v2/ 
Reset 


1 


ResetContext-v1/ 
Reset 


1 
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6.2.1 .3 MAP-PG(2) - Protection for Authentication Information except Handover 

Situations 

Table 5: PG(2) - Protection for Authentication Information except Handover Situations 



Application Context/Operation 


Protection Level 


lnfoRetrievalContext-v3/ Send 
Authentication Info 


3 


lnfoRetrievalContext-v2/ Send 
Authentication Info 


3 


lnfoRetrievalContext-v1/ Send 
Parameters 


3 


lnterVlrlnfoRetrievalContext-v3/ 
Send Identification 


3 


lnterVlrlnfoRetrievalContext-v2/ 
Send Identification 


3 



6.2.1.4 



MAP-PG(3) - Protection for Authentication Information in Handover 
Situations 

Table 6: PG(3) - Protection for Authentication Information in Handover Situations 



6.2.1.5 



Application Context/Operation 


Protection Level 
(Component level) 


HandoverControlContext-v3/ 
Prepare Handover 
(Note that the AC contains also 
other operations) 


4 


HandoverControlContext-v3/ 
Forward Access Signalling 
(Note that the AC contains also 
other operations) 


4 


HandoverControlContext-v2/ 
Prepare Handover 
(Note that the AC contains also 
other operations) 


4 


HandoverControlContext-v2/ 
Forward Access Signalling 
(Note that the AC contains also 
other operations) 


4 


HandoverControlContext-v1 / 
Perform Handover 
(Note that the AC contains also 
other operations) 


4 


HandoverControlContext-v1 / 
Forward Access Signalling 
(Note that the AC contains also 
other operations) 


4 



MAP-PG(4) - Protection of non location dependant HLR data 
Table 7: PG(4) - Protection of non location dependant HLR data 



Application Context/Operation 


Protection Level 


AnyTimelnfoHandlingContext-v3 / 
AnyTimeModification 


1 
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6.3 MAPsec protection profiles 



Protection profiles can be individual protection groups or particular combinations of protection groups. MAP protection 
profiles are coded as a 16 bit binary number where each bit corresponds to a protection group. The protection that shall 
be applied to a MAPsec message is uniquely identified by the combination of PPRI and PPI. 

This specification contains the MAPsec protection profiles that are identified with PPRI having value 0. Currently only 
5 groups are defined, the rest are reserved for future use. 

Table 8: Protection profile encoding 



Protection profile bit 


Protection group 





No protection 


1 


Reset 


2 


Authentication information except handover situations 


3 


Authentication information in handover situations 


4 


Non-location dependant HLR data 


5-15 


Reserved 



Protection profiles shall be bidirectional. 
The following protection profiles are defined. 



Table 9: Protection profile definition 



Protection 

profile 

name 


Protection group 


PG(0) 

No 

protection 


PQ(1) 
Reset 


PG(2) 

Authlnfo 

except 

handover 

situations 


PG(3) 
Authlnfo in 
handover 
situation 


PG(4) 

Non-location 
dependant 
HLR data 


Profile A 


</ 










Profile B 




V 


S 






Profile C 




V 


S 


•/ 




Profile D 




V 


S 


S 


V 


Profile E 




V 


Y 




V 



7 Security Association and Key Management 

Procedures 

This clause contains details on the procedures used by the KACs to negotiate new SAs over the Zd interface. 



7.1 



Inter-PLMN Procedure 



KACs from different PLMNs will use MAPsec Dol [7] and IKE to set up MAPsec SAs for use between their PLMNs. 
The information needed to negotiate the new SAs is held in the KAC-SPD-MAP. The KAC shall assign the MAP 
Encryption Algorithm Identifier onto the MAPsec Dol TransformID [7] when negotiating a new pair of MAPsec-SA. 
Similarly the KAC shall assign the MAP Integrity Algorithm Identifier onto the authentication algorithm attribute of the 
SA [7] for IKE phase 2 when negotiating a new pair of MAPsec-SA. The details of these assignments are ffs. The KAC 
shall not use the Key Length or Key Rounds Attributes of the S A for IKE phase 2 as this information is implicitly 
available for the partner KAC via the used TransFormlD. The negotiated SA Life Duration shall be transformed into the 
Hard Expiry Time in the MAPsec S A. It should be noted that although part of an SA, the Soft Expiry Time is not 
negotiated by the KACs. The value of Soft Expiry Time is set by local policy in the KAC. 

Editor's note: The mapping between MAPsec Dol and MAPsec SA algorithms needs specifying. 
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7.2 Intra-PLMN Procedure 

A KAC must create new MAPsec SAs to enable communication between NEs in its PLMN. It does this using the data 
stored in KAC-MAP-SPD except it must transform the SA Lifetime given in KAC-SPD-MAP into a MAPsec Hard 
Expiry Time and generate the relevant cryptographic keys. The value of Soft Expiry Time is set by local policy in the 
KAC. 



8 Local Security Association and Policy Distribution 

The KAC transmits SAs and security policy information to the NEs in the same PLMN. The method of transmitting this 
data to the NEs must satisfy the following requirements: 

The push mechanism requires the KAC to maintain active SAs with all other networks that MAP signalling is 
exchanged with. The KAC internally supervises the SA lifetime and performs automatic SA renewal with all 
other networks that MAP signalling is exchanged with. 

If new SAs are available, the KAC distributes these SAs to the NEs that require them, according to the KAC 
policy. The KAC shall provide fresh SAs to its NEs for a specific network in time before the soft expiry time of 
the current active SA has been reached. 

The NEs shall ensure that only Ze-messages sent by a KAC in the same security domain are accepted. 
Depending on the security domain policy, the NE may only accept Ze-messages from one or more specific 
KACs within the domain, out of the set of KACs in that domain. 

The KAC shall ensure that only Ze-messages sent by a NE in the same security domain are accepted (Otherwise 
an attacker could, e.g. by sending false messages, force the KAC to overload the NE's). 

The KAC shall be able to know whether the MAP-NE needs MAPsec -SAs only for internal communication 
within the security domain. 

The Ze Interface shall be able to provide cryptographical protection against the insertion of, or tampering with, 
messages by an attacker. Furthermore, it shall be possible to protect cryptographically messages containing 
sensitive information against eavesdropping. 

Editors' note: It is a working assumption of S A WG3 that the Ze Interface protocol will be IP-based, in which case it 
will be protected using NDS/IP. 

8.1 SA Distribution Procedure 

Editor's note: The aim of the text below is to provide a functional description of the Ze-interface as a starting point 
for the stage 3 specification. The full details of the interface are ffs and should be resolved in the stage 3 
work. 

This clause describes message flows for an extended push mechanism for MAPsec SA distribution over the Ze 
interface. 

Case 1: Initial registration and SA distribution 

To initiate communication with the KAC, each NE that requires MAPsec SAs initially registers with the KAC to obtain 
these SAs. The KAC then, according to the KAC policy, pushes the full set of active SAs that the NE requires (defined 
by network policy) to the NE, such that the NE receives all required SAs directly after registration. The "action" 
indicator is set to "REPLACE" to indicate that the NE shall use the S A_List as its new set of SAs, replacing all SAs that 
are currently in the NE's SADB. 

The NE acknowledges the ZE_pushSA message after successfully installing the SAs in its SADB. Otherwise it 
responds with an error message (tbd). 

KAC NE 

< ZE_register(N E_l D) - 



ZE_pushSA(action=REPLACE, SAJJst) 
ZE_ack(NE_ID, [error]) 
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Case 2: Subsequent SA distribution (normal case) 

The KAC sends a ZE_pushSA message when a new SA is negotiated by the KAC to all NEs that require this SA. It is 
allowed to send several SAs as a list within a single ZE_pushSA message. The "action" indicator is set to "ADD" to 
indicate that the NE shall add the SA_List to its current SADB. 

The NE acknowledges the ZE_pushSA message after successfully installing the SAs in its SADB. Otherwise it 
responds with an error message (tbd). 

KAC NE 

ZE_pushSA(action= ADD, SA_List) > 

< ZE_ack(NE_ID, [error]) 

NOTE: The message format for the initial ZE_pushSA and the ZE_pushS A for SA updates is the same for both 
operations, since the parameter "SA_List" represents a single or a list of SAs. 

Case 3: Handling of inconsistent NE states 

In case of any event in a NE that leads to an inconsistent S A database in a NE, this NE sends a new register message, 
and receives the full set of active SAs from the KAC. The KAC, when receiving a new registration of an already 
registered NE, just updates any old registration with the new one. 

NOTE: This step is considered to be relatively unlikely. 

Case 4: SA revocation/removal 

In case the revocation of an SA is required, the KAC sends a ZE_pushS A message identifying a list of the SAs to be 
removed to all NEs currently using them (the parameter SA_ID is tbd., but must uniquely identify the SA to be revoked. 
For example this can be the combination of SPI and destination PLMN_ID). A list of SAs may be added within the 
same ZE_pushSA (replacing the removed SAs). The "action" indicator is set to "REMOVE" to indicate that the NE 
shall delete the list of SAs identified in S A_ID_List from its current SADB, and the action "ADD" may be subsequently 
used to add the SAs contained in SA_List to its SADB. 

The NE acknowledges the ZE_pushSA message after successfully removing the SAs from its SADB. Otherwise it 
responds with an error message (tbd). 

KAC NE 

ZE_pushSA(action=REMOVE, SAJDJJst, 

action=ADD, SA_List) > 

< ZE_ack(NE_ID) 

NOTES: 

1) As the NEs in this push model do not have the option to request specific SAs, it is necessary to transmit 

the complete set of SAs from the KAC to the NE in cases 1 and 3. 

2 The replacement of a compromised S A which needs to be revoked, described in case 4, could 

alternatively be done in two steps: by first sending a revoke operation, followed by an add operation as 
described in case 2. 

3) The extended push mechanism, as described above, may be used to distribute policy information from the 

KAC to the NEs in a quite similar fashion, by using a SP_List, security policy list parameter instead of 
the SA_List parameter. 
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Annex A (informative); 
Void 
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Annex B (normative): 
MAPsec message flows 



Imagine a network scenario with two MAP-NEs at different PLMNs (NEa and NEb) willing to communicate using 
MAPsec. Figure 1 presents the message flow. 



PLMNA 



PLMNB 




© 



Zf 



©® 




Figure 1. MAPsec Message Flow 

According to Figure 1, when MAP -NEa (NEa) from PLMN A wishes to communicate with a MAP -NEb (NEb) of 
PLMN B using MAP protocol, the process is the following: 

As the Sending Entity, NEa performs the following actions during the outbound processing of every MAP message: 

1 . NEa checks its Security Policy Database (SPD) to check if MAP security mechanisms shall be applied towards 
PLMN B: 

a) If the SPD does not mandate the use of MAPsec towards PLMN B, then normal MAP communication 
procedures will be used and the process continues in step 4.b. 

b) If the SPD mandates the use of MAPsec towards PLMN B, then the process continues at step 2. 

c) If no valid entry in the SPD is found for PLMN B, then the communication is aborted and an error is returned 
to the MAP user. 

2. NEa checks its Security Association Database (SAD) for a valid Security Association (SA) to be used towards 
PLMN B. In the case where more than one valid SA is available at the SAD, NEa shall choose the one, the soft 
expiry time of which will be reached next. 

a) In case protection of MAP messages towards PLMN B is not possible (e.g. no SA available, invalid SA. . .), 
then the communication is aborted and an error is returned to MAP user. 

b) If a valid S A exists but the MAP dialogue being handled does not require protection (Protection Mode 
applies to all the components of the dialogue), then either the original MAP message in cleartext is sent in 
step 4.b, or a MAPsec message with Protection Mode is created in step 3. 

c) If a valid S A exists and the MAP dialogue being handled requires protection, then the process continues at 
step 3. 

3. NEa constructs the MAPsec message towards NEb using the parameters (keys, algorithms and protection 
profiles) found in the SA. 

4. NEa generates either: 

a) MAPsec message towards NEb. 

b) An unprotected MAP message in the event that the SPD towards NEb or protection profiles for that specific 
MAP dialogue so allows it (La. or 2.b.). 
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At the Receiving Entity, NEb performs the following actions during the inbound processing of every MAP message it 
received: 

5. If an unprotected MAP message is received, the process continues with step 6. 

Otherwise, NEb decomposes the received MAPsec message and retrieves SPI and Original component Id from 
the security header. 

6. NEb checks the SPD: 

An unprotected MAP message is received: 

a) If an unprotected MAP message is received and fallback to unprotected mode is allowed, then the 
unprotected MAP message is simply processed (Process goes to END) 

b) If an unprotected MAP message is received and the 'MAPsec operation components table' of the SPD does 
not mandate the use of MAPsec for the included 'Original Component Identifier', then the unprotected MAP 
message is simply processed (Process goes to END) 

c) If an unprotected MAP message is received, the 'MAPsec operation components table' of the SPD mandates 
the use of MAPsec for the included 'Original Component Identifier' and fallback to unprotected mode is 
NOT allowed, then the message is discarded. 

If the MAP dialogue is still open and it is waiting for an answer, NEb also reports an error back to NEa. 

A MAPsec message is received, NEb checks SPI in the SPD: 

d) If SPI is not in SPD or there is no valid entry for the PLMN associated with SPI in the SPD, then the message 
is discarded and an error is reported to MAP user. 

If the MAP dialogue is still open and it is waiting for an answer, NEb also reports an error back to NEa. 

e) If a MAPsec message is received, but the SPD indicates that MAPsec is NOT to be used, then the message is 
discarded and an error is reported to MAP user. 

If the MAP dialogue is still open and it is waiting for an answer, NEb also reports an error back to NEa. 

f) If a MAPsec message is received and the SPD indicates that MAPsec is required, then the process continues 
at step 7. 

7. NEb checks its SAD to retrieve the relevant SA-information for processing of the MAPsec message: 

a) If the received SPI points to a valid S A, then NEb uses the 'Original Component Identifier' in the MAPsec 
header to identify the protection level that has to be applied to the component indicated, according to the 
protection profile indicated in the SA. If Protection Mode was applied, then the MAP message is simply 
processed (Process goes to END). Otherwise The process continues at step 8. 

b) If the received SPI does not point to a valid S A, the message is discarded and an error is reported to MAP 
user. If the MAP dialogue is still open and it is waiting for an answer, NEb also reports an error back to NEa. 

8. Freshness of the protected message is checked by ensuring the Time Variant Parameter (TVP) is in an acceptable 
window. Integrity and encryption mechanisms are applied to the message according to the identified protection 
level, by using the information in the SA (Keys, algorithms). 

a) If the result after applying such mechanisms is NOT successful then the message is discarded and an error is 
reported to MAP user. If the MAP dialogue is still open and it is waiting for an answer, NEb also reports an 
error back to NEa. 

b) If the result after applying such procedures is successful, then NEb has the cleartext MAP message NEa 
originally wanted to send NEb. The cleartext MAP message can now be processed (Process goes to END) 

END: A cleartext MAP message is available at NEb. 

In the event the received message at NEb requires an answer to NEa (Return Result/Error), NEb will perform the 
process in steps 1 to 4 acting as the Sender and NEa will perform the process in steps 5 to 8 acting as the Receiver. 
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In the event a MAPsec enabled NE initiated a secured MAP communication towards a non-MAPsec enabled NE and 
the MAPsec enabled NE received an error indication of such circumstance (i.e. " ApplicationContextNotSupported"). 
The MAPsec enabled NE shall check whether "Fallback to Unprotected Mode" is allowed: 

If NOT allowed, then the communication is aborted. 

If allowed, then the MAPsec enabled NE shall send an unprotected MAP message instead. 

The same procedures shall apply to secure MAP communications between MAP-NEs in the same PLMN. 

NOTE: Because various error cases may be caused by active attacks, it is highly recommended that the cases are 
reported to the management system. 
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